[% setvar title The Perl 6 Summary for the week ending 20040215 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20040215'></a><h1>The Perl 6 Summary for the week ending 20040215</h1>
<p>In his talk on Parrot at OSCON last year, Dan said that Parrot would
have objects 'by the end of the week'. It's been a very long week, and
it's not finished yet.</p>
<p>Right, venting over, time for the summary. I'll start with
perl6-internals, as always. Actually, we're starting slightly before
the usual start of the week because about half an hour after I sent
last week's summary off I realised I'd completely missed a couple of
threads.</p>
<a name='Some minor decisions and timetables'></a><h2>Some minor decisions and timetables</h2>
<p>Dan made a few design decisions and outlined a release timetable for
the next release of Parrot (which was initially set to be Valentine's
Day, but the appeal of February 29th for a Leap Parrot release proved
to be greater).</p>
<p><a href='http://groups.google.com/groups?selm=a06010205bc459600096b@' target='_blank'>groups.google.com</a>[172.24.18.98]</p>
<a name='Why didn't I mention this last week?'></a><h2>Why didn't I mention this last week?</h2>
<p>Jens Rieks earns a &quot;Wow, cool!&quot; from me with his parrot version of
Data::Dumper. Way to go Jens. People were impressed.</p>
<p><a href='http://groups.google.com/groups?selm=200402051301.35111.parrot@jensbeimsurfen.de' target='_blank'>groups.google.com</a></p>
<a name='Supporting simple PMCs as keys'></a><h2>Supporting simple PMCs as keys</h2>
<p>Stéphane Payrard posted a patch to support using simple PMCs instead of
full on key PMCs for simple lookups. He and Leo discussed it, but the
patch hasn't been accepted yet.</p>
<p><a href='http://groups.google.com/groups?selm=20040209192126.GB17703@stefp.dyndns.org' target='_blank'>groups.google.com</a></p>
<a name='Keyed access to UnManagedStruct'></a><h2>Keyed access to UnManagedStruct</h2>
<p>Everyone's favourite differently capitalized O'Reilly employee,
chromatic (Maybe the new running joke should be my struggles to avoid using
his name at the start of a sentence so we don't have a falling out
cases), continued his discussion with Leo about keyed access to
Unmanaged (and presumably managed) C structs.</p>
<p><a href='http://groups.google.com/groups?selm=1076360871.2575.2.camel@localhost' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=1076389270.15055.2.camel@localhost' target='_blank'>groups.google.com</a> -- An example of chromatic's problem</p>
<a name='Backward branch, fixed'></a><h2>Backward branch, fixed</h2>
<p>Remember the problem with a backward branch that I said was Warnocked
last week. It turned out that it was fixed before I posted the
summary. They don't call Leo T&ouml;tsch the Patchmonster for nothing.</p>
<p><a href='http://groups.google.com/groups?selm=200402101351.i1ADpGQ20266@thu8.leo.home' target='_blank'>groups.google.com</a></p>
<a name='Parrot system'></a><h2>Parrot <code>system</code></h2>
<p>Dan apologized for his recent silence on list, but thought he'd be more
active from now on. He also announced that he was in the process of
adding in perl 5 style <code>system</code> support</p>
<p><a href='http://groups.google.com/groups?selm=a06010202bc4ef0a3aa78@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Parrot sort'></a><h2>Parrot sort</h2>
<p>Jens Rieks garnered more kudos with his implementation of a simple _sort
function in IMC. Leo checked it in, and you'll find it in
<b><i>library/sort.imc</i></b> in an up to date CVS distribution. Then, seemingly
in his spare time, he fixed up some SDL related stuff for chromatic.</p>
<p><a href='http://groups.google.com/groups?selm=200402111311.04736.parrot@jensbeimsurfen.de' target='_blank'>groups.google.com</a></p>
<a name='RFD: Symbol naming and IMCC2'></a><h2>RFD: Symbol naming and IMCC2</h2>
<p>Melvin Smith posted a Request For Discussion about how IMCC2 will
handle symbols and sigils. The issue seems to be that, for humans
writing code, quoting symbols is a pain. Various options were
suggested, but nothing appears to have been decided yet. (I quite like
Leo's suggestion involving declaring lexicals with a mangled name for
use in parrot, but marking it as being associated with an
<code>$unmangled_original_name</code>.)</p>
<p><a href='http://groups.google.com/groups?selm=5.1.1.6.2.20040211121042.09c2e500@pop.mindspring.com' target='_blank'>groups.google.com</a></p>
<a name='JIT and branches under the Sun'></a><h2>JIT and branches under the Sun</h2>
<p>Stephane Peiry found with the JIT on Suns; it seems that a loop that
should terminate carries on forever instead. He and Leo worked on
tracking it down, but the bug was still there by the end of the week.</p>
<p><a href='http://groups.google.com/groups?selm=20040212210728.GA1436@pittypanda' target='_blank'>groups.google.com</a></p>
<a name='Rules for method resolution?'></a><h2>Rules for method resolution?</h2>
<p>Okay, so I may have kvetched about the continuing lack of Parrot
objects earlier, but Dan's definitely working on it. This time he's
thinking about method resolution. In particular he wondered when</p>
<pre>   findmethod P4, Pobject, &quot;methodname&quot;</pre>
<p>should do the name resolution. In other words, should P4 contain the
method that was current at the time of the <code>findmethod</code> call, or a
proxy PMC that waits until the method is invoked to find the
appropriate method. The discussion seemed to come down in favour of
doing both.</p>
<p><a href='http://groups.google.com/groups?selm=a06010204bc52aa01e263@' target='_blank'>groups.google.com</a>[172.24.18.98]</p>
<a name='Object spec'></a><h2>Object spec</h2>
<p>Dan noted that he'd checked in some major revisions to PDD15 (objects!)
and suggested that people take a look. Simon Glover, Leo Tötsch and LF
had questions.</p>
<p><a href='http://groups.google.com/groups?selm=a0601020bbc52f88649a7@' target='_blank'>groups.google.com</a>[172.24.18.98]</p>
<a name='Meanwhile in perl6-language'></a><h1>Meanwhile in perl6-language</h1>
<a name='The thread that ate the mailing list'></a><h2>The thread that ate the mailing list</h2>
<p>Luke Palmer doesn't like the repetition inherent in</p>
<pre>   @sorted = sort { $^a.foo('bar').compute &lt;=&gt; $^b.foo('bar').compute }
               @unsorted;</pre>
<p>He wondered if there might be some way of rejigging <code>sort</code> to eliminate
the duplication and proposed a couple of spectacularly ugly
possibilities. And then the world exploded. It seems that nobody (on
perl6-language) actually likes the current signature of <code>sort</code>, but
nobody can quite agree on what it <i>should</i> look like. You know things
are getting hand when Dan proposes just using SQL's <code>ORDER BY</code> syntax
(even though he was joking). Simon &quot;Rubyometer&quot; Cozens proposed:</p>
<pre>   @sorted = @unsorted.sort(op =&gt; &amp;infix:&lt;=&gt;, 
                            key =&gt; { $^a.foo('bar').compute });</pre>
<p>Which, I have to confess, I rather like. Rod Adams demonstrated a truly
painful looking sort function which this summary is too succinct to
contain, see the link for details.</p>
<p>Personally, I'm amazed that a single library function could generate so
much discussion. And there's more to come next week.</p>
<p><a href='http://groups.google.com/groups?selm=20040212031134.GA16797@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=20040213041440.28310.qmail@web40802.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=402EA18A.40604@rodadams.net' target='_blank'>groups.google.com</a> -- Feel Rod's pain.</p>
<a name='Haven't I had this feeling of déja vù before?'></a><h2>Haven't I had this feeling of déja vù before?</h2>
<p>Dmitry Dorofeev pointed everyone at Scharli et al's paper on Smalltalk
Traits and proposed that Perl 6 use something similar. Which is what
Larry proposed a few weeks back, except he called Traits Roles and
propose that they also have (or mandate) state (the original Smalltalk
Traits are stateless). Aaron Sherman wondered if the Emperor was
actually wearing clothes by saying that Roles didn't seem to be
substantially different from Java interfaces. I particularly liked
chromatic's answer that &quot;interfaces completely suck while [Roles]
don't.&quot; My other favourite quote of the thread was from (who else)
Larry: &quot;The Traits paper didn't go into traits with state, though it
did mention it as a future research topic. We're just doing that future
research for them.&quot;</p>
<p><a href='http://groups.google.com/groups?selm=20040212131111.95331.qmail@onion.perl.org' target='_blank'>groups.google.com</a></p>
<a name='Announcements, Acknowledgements, Apologies'></a><h1>Announcements, Acknowledgements, Apologies</h1>
<p>Well, I've thought about it some more, and I'd like you all to welcome
chromatic as the Perl 6 Summary's official running joke. I don't
guarantee to mention him every week, but I do guarantee that I'll always
jump through hoops to avoid starting a sentence with his name when I do
mention him.</p>
<p>If you find these summaries useful or enjoyable, please consider
contributing to the Perl Foundation to help support the development of
Perl. You might also like to send me feedback at
mailto:<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>, or drop by my website.</p>
<p><a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> -- The Perl Foundation</p>
<p><a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> -- Perl 6 Development site</p>
<p><a href='http://www.bofh.org.uk/' target='_blank'>www.bofh.org.uk</a> -- My website, &quot;Just a Summary&quot;</p>
</div>
